home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 5⁄25⁄90 / 1344-TDeskScrap Bug in MA-May90 < prev    next >
Encoding:
Text File  |  1990-05-25  |  2.6 KB  |  68 lines  |  [TEXT/GEOL]
  1. Item    1280157                         25-May-90        14:13PDT
  2.  
  3. From:   D0416                           Futuresoft System Design,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:     TDeskScrap Bug in MA 2.0
  8.  
  9. Fellow MacAppers,
  10.  
  11. Below is a message from John Baxter on Compuserve about a bug that he reported
  12. about a month ago. The bug still exist in MA 2.0 final although it is noted in
  13. the Release Notes. To refresh your memory, he reported that when there is
  14. _both_ PICT and TEXT on the public scrap, TDeskScrapView will try and do a
  15. DrawPicture on the text handle instead of the picture handle resulting in a
  16. “garbage-like” display in the Clipboard window. Cut, Copy and Paste of the
  17. Clipboard, however, does function properly.
  18.  
  19. He has already sent this bug report to MacApp.Test and MacApp.Bugs.
  20.  
  21. -Ken Addison
  22.  FutureSoft System Designs
  23.  
  24. *---- M e s s a g e   f r o m   J o h n   B a x t e r   o n   C I S ---*
  25.  
  26. Fm: John Baxter 71735,1626
  27. To: All
  28.  
  29.   Too late for a fix in MacApp 2.0, I reported the problem with both TEXT and
  30. PICT types in the Desk Scrap.  This problem appears as the third known bug in
  31. the MacApp 2.0 Release Notes (thanks!!).  As I was applying my fix for the
  32. problem (reversing the two calls to LookForScrapType, as shown here:)
  33.  
  34.  fHavePicture := LookForScrapType('PICT'); { JWB Swapped 5/24/90. }
  35.  fHaveText := LookForScrapType('TEXT');
  36.  
  37. (lines 162 and 163 of UMacApp.TDeskScrapView.p), I believe I see another
  38. problem (I wish I'd caught it before!). LookForScrapType calls GetScrap.
  39. GetScrap is a potential heap-compactor (according to "Inside Macintosh X-Ref"
  40. from Addison-Wesley).  Hence, I believe the two assignments to fields of SELF
  41. in those two lines are examples of dangerous use of de-referenced pointers.
  42.  
  43. This may well not result in problems often enough to have been noticed, since
  44. I suspect the heap is in a somewhat empty state at the time this code is
  45. executed.
  46.  
  47. For my own purposes, I'm going to change my fix, to use a new temporary
  48. variable:
  49.  hasScrapType: BOOLEAN;
  50.  
  51. Then the code becomes
  52.    { JWB 5/24/90 Reversed the sequence and used a temporary variable. }
  53.  hasScrapType := LookForScrapType('PICT');
  54.  fHavePicture := hasScrapType;
  55.  hasScrapType := LookForScrapType('TEXT');
  56.  fHaveText := hasScrapType;
  57.  
  58.  I hope the above is (a) correct, and (b) helpful.
  59.    --John
  60.  
  61. PS--The above has been AppleLinked (via CI$) to Apple.Bugs and MacApp.Test.
  62. Ken Addison, if you agree with the above, would you be so kind as to copy it to
  63. MacApp.TECH$ on AppleLink (I understand that large address lists cause the
  64. gateway from CI$ problems).  Many thanks.
  65.  
  66. *--- END OF CIS Message ---*
  67.  
  68.